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Abstract 

The Procedural Reasoning System (PRS) is a gen- 
eral purpose reasoning system that is particularly 
suited for use in domains in which there are prede- 
termined procedures for handling the situations that 
might arise. We have just completed an implemen- 
tation of PRS written in C++, which we call the 
University of Michigan Procedural Reasoning System 
(UM-PRS). In this paper, we show how UM-PRS pro- 
vides a critical level of representation for robotic ap- 
plications in unpredictable domains, because it allows 
robotic vehicles to pursue long-term goals by adopt- 
ing pieces of relevant procedures depending on the 
changing context, rather than having to blindly follow 
a prearranged plan. Specifically, UM-PRS has been 
used to control a real outdoor vehicle that changes its 
behavior based on what it sees in its environment. In 
turn, this provides the substrate for coordinating mul- 
tiple robotic vehicles, allowing them to represent joint 
procedures and to infer each others plans through ob- 
servation. 

Introduction 

We have been involved in a project which will, at its 
terminus, result in a team of robotic vehicles that are 
capable of autonomously working together while per- 
forming reconnaissance and other militarily relevant 
tasks. High-level plans for these vehicles will typi- 
cally be in the form of mission plans and annotated 
maps. A mission plan is a declarative representation 
of the vehicles’ major goals. Based on this, a human 
annotates a map showing topographical and strategic 
features to indicate where along planned routes some 
changes in each robotic vehicle’s behaviors must be 
made (turned on, turned off, or parameters modified). 
Thus, the annotated map represents a “program” to 
be executed by the vehicles, where crossing certain 
spatial lines trigger a vehicle to execute the next step 
of its program. 

The annotated map representation 8 is incomplete 
in that it lacks the richness required for robotic con- 
trol in unpredictable, dynamic environments. Blindly 
following the preprogrammed sequence of behaviors 
might be hazardous (if the context in which the se- 
quence was formed changes) or impossible (if the ve- 
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hide loses track of its position on the map or if its 
control is temporarily taken over by a human). There- 
fore, it is important that the map and mission plan be 
accompanied by more general knowledge about why 
certain actions are being taken and in what context. 
Military doctrine, as laid out in documents such as 
field manuals, contains large numbers of standard op- 
erating procedures (SOPs) that should be selectively 
invoked as conditions and objectives change. In fact, 
an annotated map for a mission plan typically repre- 
sents a particular sequence of SOPs that are expected 
to be useful. For a flexible, autonomous system to 
succeed, however, the suite of SOPs must be avail- 
able to the system at runtime. 

The Procedural Reasoning System 4- ^ is a general 
purpose reasoning system particularly suited for use 
in domains in which there are predetermined proce- 
dures for handling the situations that might arise. 
This makes it very applicable in domains such as 
that discussed above. However, until recently, there 
has not been an implementation of PRS that is freely 
available for use. We have just completed an imple- 
mentation of PRS written in C++, which we call the 
University of Michigan Procedural Reasoning System 
(UM-PRS). 

In this paper we discuss the details of our initial im- 
plementation. Our implementation is novel in terms 
of both knowledge representations and control struc- 
tures all written in C++ to meet the needs of efficient 
real-time robotic control. First, we briefly introduce 
the general concepts of procedural reasoning systems, 
the specific representations and the interpreter of the 
initial UM-PRS version. Second, we illustrate how 
UM-PRS serves as an important intermediate level of 
representation and reasoning between the high-level 
mission plan and the executable annotated map, and 
how it can interface with these levels. We also il- 
lustrate how the flexibility provided by UM-PRS al- 
lows autonomous responses beyond those permitted 
by annotated maps alone. Third, we briefly describe 
how UM-PRS has been used, to date, in the dynamic 
control of a real outdoor vehicle and how UM-PRS 
provides a basis for multi-vehicle coordination, both 
in terms of allowing the automated formation of be- 
lief networks that a vehicle can use to infer the plans 
of others through observation, and in terms of rep- 
resenting the collective activities of vehicles and the 
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roles that they can play. Finally, we summarize the 
current status of UM-PRS and the ongoing improve- 
ments that we are making in order to realize the full, 
flexible autonomous capabilities in our multivehicle 
system. 

Procedural Reasoning System 

Developing reasoning systems that can reason and 
plan in continuously changing environments in real- 
time is emerging as an important area of application 
of Artificial Intelligence. In this section, we describe 
basic features of the Procedural Reasoning System 
(PRS) that motivated us to adopt PRS as a concep- 
tual framework for our system. 

The Procedural Reasoning System 4-6 is a general- 
purpose reasoning system, integrating traditional 
goal-directed reasoning and reactive behavior. Be- 
cause most traditional deliberative planning systems 
formulate an entire course of action before starting 
execution of a plan, these systems are brittle to the 
extent that features of the world or consequences of 
actions might be uncertain. In contrast, the Procedu- 
ral Reasoning System continuously tests its decisions 
(both high- and low-level) against its changing knowl- 
edge about the world, and can redirect the choices 
of actions dynamically while remaining purposeful to 
the extent of the unexpected changes to the environ- 
ment. 

PRS thus is not a planning system in the traditional 
AI sense, in that PRS does not concentrate on search- 
ing for sequences of primitive actions that lead to spe- 
cific goals. Instead, PRS is a plan execution system: 
it assumes that it already has “plans” (procedures) 
for achieving various goals in various contexts; how- 
ever, it might string together actions in unexpected 
ways as it dynamically chooses among procedures and 
subprocedures in a changing environment. 

Typically, accomplishing a mission in a military set- 
ting is much more similar to the plan execution ac- 
tivities of PRS than to the activities of traditional 
planning systems. Procedures for military tasks such 
as reconnaissance are developed and learned off-line, 2 
and training involves mastering the selection and ex- 
ecution of predefined procedures. These procedures 
may contain knowledge about both cognitive (such as 
situation assessment) and physical actions, and they 
can be arbitrarily complex. Often, a “step” in one 
procedure (such as “move to assembly area”) might 
itself correspond to several sub-procedures, each ap- 
propriate in different contexts. 

PRS is conceptually geared for representing pre- 
cisely this kind of procedural information. Several 
features that make PRS particularly powerful as a 
situated reasoning system 6 are as follows: 

• The semantics of its plan (procedure) representa- 
tion, which is important for verification and main- 
tenance. 

• Its ability to expand and act on partial plans. 

• Its ability to pursue goal-directed tasks while be- 
ing responsive to changing patterns of events in 
bounded time. 



Figure 1: PRS System Structure 3 


• Its facilities for managing multiple tasks in real 
time. 

• Its default mechanisms for handling the environ- 
ment’s stringent real-time demands. 

• Its metalevel (or reflexive) reasoning capabilities. 

PRS consists of (1) a database (called World Model) 
containing current beliefs or facts about the world; 
(2) a set of current goals to be realized; (3) a set of 
plans (called Knowledge Areas) describing how cer- 
tain sequences of actions and tests may be performed 
to achieve given goals or to react to particular situ- 
ations; and (4) an intention structure containing those 
plans that have been chosen for eventual execution 
(Figure 1). An interpreter (or reasoning mechanism) 
manipulates these components, selecting appropriate 
plans based on the system’s beliefs and goals, placing 
those selected on the intention structure, and execut- 
ing them. 3 

The system interacts with its environment, includ- 
ing other systems, through its database (which ac- 
quires new beliefs in response to changes in the envi- 
ronment) and through the actions that it performs as 
it carries out its intentions. 3 

UM-PRS 

In our particular implementation of PRS, we have 
been concerned to a large extent with the specific re- 
quirements of the military task domain we have out- 
lined, and which we will discuss further below. Thus, 
whereas some versions of PRS have been developed 
(typically in Lisp) to be extremely general, our goal 
has been to identify the crucial features of PRS for 
our application domain, and to implement them in a 
robust way in C++. Some of the design and imple- 
mentation decisions that we have made follow. 

World Model 

In our implementation, WM is a database of facts 
which are represented as relations. A relation has a 
name and a variable number of fields. Initial facts 
are asserted at the beginning of a UM-PRS program 
by the user, and other facts can be either asserted or 
retracted by the KAs, which will be explained below. 
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Knowledge Area s 

A Knowledge Area (KA) is a declarative procedure 
specification of how to satisfy a system goal or query. 
It consists of the purpose (a goal, query, test, or world 
model assertion or retraction) for executing the KA, 
the context in which the KA is applicable, a graph- 
ical network called the body which specifies what is 
required to satisfy the purpose in terms of primitive 
functions, subgoals, conditional branches, etc., and a 
symbol table which holds values for variables when a 
KA is instantiated for a specific situation. The con- 
text consists of a mixed sequence of patterns to be 
matched against the WM and expressions to be satis- 
fied using the variable bindings generated during the 
matching. 

A SOAK (Set Of Applicable KAs) is a collection of 
KAs which have been instantiated to achieve a goal 
(purpose) that has just been activated. Each KA in 
the SOAK is applicable to the specific situation, as 
one role of the context is to filter out KAs that are 
not relevant to a particular situation. 

The body describes the procedure’s steps, consist- 
ing of a network of actions. The body can be viewed 
as a plan schema. The schema is instantiated with 
the bindings which are generated when the purpose 
and the context of the KA are checked during SOAK 
generation. 

Actions 

Actions are the arcs in a KA body that consti- 
tute either primitive actions or subgoals to achieve. 
A “primitive” action is a behavior or activity that 
can be executed directly. Any other type of action 
represents a) a goal that needs achievement, mainte- 
nance, or to be waited upon b) a query, c) a test, or d) 
an assertion or retraction of world model information. 
Actions are represented by a base class that holds in- 
formation regarding the KA in which the action is 
found and the action name. Each of the types of ac- 
tions are represented by a derived class that maintains 
such information as function pointers (for a primitive 
action), the expression to evaluate (for a test), a goal 
or query expression, or a world model relation to as- 
sert or retract. 

Goals 

Goals in UM-PRS are the world states that the 
system is trying to bring about (or maintain, etc.). 
A goal can be either a top-level goal, which controls 
the system’s highest order behavior, or a subgoal ac- 
tivated by the execution of a KA arc. 

Intention Structure 

The intention structure acts as the run-time stack 
for the system. It keeps track of the progress of each 
high-level goal and all of the subgoals. The intention 
structure suspends, resumes, cancels, and proceeds 
with execution of goals in much the same way as an 
operating system. The intention structure maintains 
information about what KAs are currently active, as 
well as what actions in each KA are to be executed 
next. As there are conditional branches in a KA, the 


intention structure must also maintain information re- 
garding the success or failure of branches. 

The Interpreter 

The UM-PRS interpreter is similar to the inter- 
preter described for PRS: It is what controls the exe- 
cution of the entire system. Whenever there is new or 
changed information in the world model or goal list, 
the interpreter determines a new SOAK. From this 
SOAK is selected the most appropriate KA, which is 
placed in the intention structure. When there are 
no SOAKs being generated, the interpreter checks 
the intention structure for the currently active KAs 
and executes the next primitive action. If this ac- 
tion changes the goal list (by creating a subgoal or 
by satisfying a goal) or world model, a new SOAK is 
created and the cycle starts over. If a new SOAK is 
not created, then the next arc in a leaf- level KA is 
executed. 

With this implementation, the interpreter facili- 
tates switching to more important goals according to 
the situation. This implementation also stays com- 
mitted to one method of achieving a goal by not recon- 
sidering alternatives unless the current method fails. 
The UM-PRS interpreter is different from the PRS in- 
terpreter in that there is currently no metalevel con- 
trol, although we plan on adding that in the near 
future as we enrich the set of KAs such that we could 
have many KAs applicable in overlapping situations. 

Example 

We began by briefly describing the incomplete- 
ness of the annotated map representation 8 in unpre- 
dictable, dynamic environments. In this section, we 
show examples of using both the annotated map rep- 
resentation and the UM-PRS system. We first show a 
clear correspondence between the annotated map rep- 
resentation and the UM-PRS representation when ge- 
ographical events are the main triggers of the actions. 
In the second example, we show the limitation of the 
annotated map representation and, in contrast, the 
richness of UM-PRS when general (non-geographical) 
events trigger actions. 

Figure 2 is an example annotated map representa- 
tion of a simple scenario of getting to an observation 
point from the assembly area using road following and 
STRIPE (a waypoint following method) alternatively. 
The actions to be taken are annotated along the cir- 
cles in the map. Figure 3 is an example UM-PRS 
knowledge area that generalizes the procedure on the 
annotated map. The actions in the KA body roughly 
correspond to the sequence of actions represented in 
the annotated map, and the KA representation (con- 
text and body) is somewhat simplified to highlight 
the correspondence between the two representations. 
A full detailed working example is presented in the 
Appendix. 

An important advantage to using the procedural 
representation over the annotated map representation 
is that the correspondence between mission objectives 
and map markings is made explicit. That is, with an 
annotated map, the (human) mission planner has a 
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Assemble 



NAME: "Get to OP" 

PURPOSE: (ACHIEVE get_to_OP $op) 
CONTEXT: (FACT assembled "True") 
BODY: 

o 

(EXECUTE Depart) 


o — 

(QUERY Ari|ived_OP $value) 


o 


(ACHIEVE 


Follow_Road) 


o 


(TEST (== $valu>^tnie M )) (TEST (=== $value "False")) 

o b 

(ACHIEVE RSTA) (ACHIEVE STRIPE) / 


o 


o 


Figure 3: UM-PRS KA 


mission in mind, along with an operating procedure to 
accomplish it. The overall operating procedure is not 
explicitly represented anywhere, but only the steps 
are given in the annotations. However, the human 
interface using a UM-PRS-based system can be quite 
different. The human can specify an objective, and 
UM-PRS will retrieve appropriate KAs. In order to 
instantiate those KAs, UM-PRS must bind variables 
to values, and those values could include geographi- 
cal information (where the assembly area is, or which 
road to follow). Thus, while the user will certainly 
still point to locations and regions on a map, he or 
she will do so in response to the needs of the explicitly- 
represented, standard operating procedures currently 
being elaborated by UM-PRS. 

The second example scenario is shown in Figure 4. 
The vehicle starts out by issuing a command to start 
the road-following behavior. This moves the vehicle 
forward until it reaches a cone or goes past a maxi- 
mum allowed distance. If it passes the max distance 
without seeing the cone, the vehicle stops and the 
demo is done. If the vehicle detects the cone, it ap- 
proaches the cone and starts off-road behavior until 
it sees that it has reached the end point. When the 
vehicle has reached the end point, the demo is done. 

The idea of the demo is to show that UM-PRS can 
be used to represent conditional actions based on non- 
geographical events such as cone detection. The cone 
can be placed anywhere along the road, or there may 
be no cone at all. Such non-geographical events are 
hard to annotate in a map. The full KA description 
of this demo is presented in the Appendix. Note that 


the general capability of pattern-directed invocation 
of UM-PRS makes it possible to represent high-level 
choices of very different behaviors as well as simple 
non-geometric events. So, for example, representing 
procedures for context changes such as “running for 
cover” after having “been discovered by enemy” is 
easy to represent in UM-PRS, rather than cluttering 
up regions of the map with annotations. 

Experiments 

In this paper, we have described our implemen- 
tation of UM-PRS. Currently, we are experimenting 
with using UM-PRS for robotic control of two indoor 
mobile robots, and also of an outdoor robotic vehicle 
(Figure 5). The scenario being used for our experi- 
ments is a reconnaissance task in a military domain. 
Typically, the means of satisfying the task’s goals are 
described in terms of procedures to follow in specific 
situations. These procedures correspond exactly to 
KAs, with the context and the purpose specific to the 
situation in which it is applicable. 

One thing we have to note is that all the actions de- 
scribed in the KA body should eventually map down 
to primitive actions (C or C++ functions) which are 
directly executable on the real robot or vehicle. Since 
our implementation is done in C++, the interface be- 
tween KA actions and real primitive control functions 
is very natural and efficient. 

UM-PRS: Toward Multi- vehicle Coordination 

Many tasks of interest, particularly in the military 
domain, require the concerted efforts of several play- 
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ers. In other words, they require teamwork. Recently, 
Georgeff ’s colleagues 7 have explored extensions to the 
procedural representation to model different “roles” 
played in team procedures, and have developed al- 
gorithms for assigning roles to potential team mem- 
bers. These capabilities need to be incorporated into 
UM-PRS to capture the notion of roles in military 
procedures, such as the roles of “bounder” and “over- 
watcher” in a bounding-overwatch procedure. Since, 
in such a procedure, the vehicles take turns watch- 
ing and moving as they leapfrog across an area, the 
roles will be assigned and reassigned dynamically in 
the course of the procedure. 

Having each adopted its role in a shared, team pro- 
cedure, a vehicle can then work to achieve its goals 
in the procedure. However, since how it chooses to 
achieve its goals can impact the choices available to 
other vehicles in how they achieve their goals, some 
additional coordination is often needed. In essence, 
while the vehicles might commit to a team plan at an 
abstract level, they also might have to commit ahead 
of time to how they might (or might not) elaborate 
their plans into detailed actions. Anticipating and 
making necessary commitments ahead of time (be- 
fore they move into the field where communication 
is more risky and error prone) should be done, but 
overcommitment should be avoided lest the vehicles 
commit to specific courses of action that they later 
find to be subopt imal or even ineffective. Thus, while 
the conceptual framework of PRS emphasizes delayed 
commitment to action until the action must be taken, 
coordination requires some degree of commitment to 
the future. Extending UM-PRS to provide this capa- 
bility is one of our ongoing efforts. 

Also, once in the field, some coordination might be 
needed, and is typically done through communicating 
about plans, goals, or beliefs about the world. Each 
of the involved vehicles can reason about this infor- 
mation in order to detect possible conflicts, improve- 
ments, synergies, etc. As mentioned before, explicit 
communication may not always be possible, however, 
due to such situations as hostile vehicles in the vicin- 
ity, environmental noise, and broken equipment. Plan 


recognition is the process of inferring the same infor- 
mation (the motivating goals or beliefs of a vehicle) 
based upon sensory observation of that vehicle’s ac- 
tions. Once the plans have been inferred, the same 
reasoning process can be used to make decisions re- 
garding coordination. 

One of the most significant issues that arises is that 
plans of the robotic vehicles will be in the form of 
UM-PRS Knowledge Areas, which are not conducive 
to performing plan recognition. In response to this, 
we are developing a system that will automatically 
convert the plans of the other team vehicles into a 
representation amenable to plan recognition, namely 
belief networks. Belief networks, also called Bayesian 
networks , 1 provide the framework and mechanisms for 
performing probabilistic reasoning about the relation- 
ship between the observations of a vehicle’s actions 
and the vehicle’s reasons (plans, goals, etc.) for per- 
forming that action. While manual construction of 
belief networks to represent the UM-PRS plans can 
be done, it is extremely time consuming and subject 
to variability. When considering the large number 
of possible KAs for complex tasks, and hence the 
large number of possible plans that might be cre- 
ated and executed, manual conversion of the plans 
becomes impractical. By providing an automated sys- 
tem, this process can be performed quickly, efficiently, 
and without variation. 

Conclusions 

The representation and control scheme that we 
have implemented has proven to be sufficiently pow- 
erful for planning and execution in procedurally rich 
domains, specifically in a robotic reconnaissance task. 
Our experiments have shown the initial implemen- 
tation to reactively switch between goals, while re- 
maining committed to the current method of achiev- 
ing each goal. We are actively working on many ex- 
tensions to the initial implementation (such as met- 
alevel control, and coordination mechanisms, as out- 
lined above) that will make it even more powerful and 
flexible. 
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Appendix: Example system 

The example system included here as a demo for 
UM-PRS is an early version of a KA library and prim- 
itive functions developed to demonstrate the applica- 
bility of UM-PRS to mobile robot tasks. 

The idea of the demo is to show that a planner can 
be used as a triggering device to enable and change 
vehicle behaviors. 

• The vehicle starts out by issuing a command to 
start the YARF road following behavior. This 
moves the vehicle forward until it reaches a cone 
or goes past a maximum allowed distance. 

• UM-PRS will wait until the vehicle is stopped (0 
= not stopped, 1 = stopped). UM-PRS then will 
query to see if the vehicle has seen the cone or 
passed the max distance. 

• If it passes the max distance, then the vehicle stops 
and the demo is done. 

• If the vehicle detects the cone, then the vehicle 
stops and waits for the next behavior. 

• If the vehicle sees the cone, then UM-PRS will issue 
an Approach Cone behavior. UM-PRS will then 
wait until the vehicle has stopped and check if it 
has reached the cone. 

• If the vehicle has reached the cone, then UM-PRS 
will issue an Off Road behavior. UM-PRS will wait 
until the vehicle has stopped and reached the end 
point. 

• When the vehicle has reached the end point, then 
the demo is done. 

KA code 

GOALS: 

(ACHIEVE cone_demo) 

FACTS : 

(vehicle_status "True") 

(demo_done "False") 

(cone_found "False") 

( cone_reached " False " ) 
(vehicle_reached "False") 
(vehicle_maxdist "False") 
(vehicle_stopped "True") 


// 

// KA 1 

// 

KA { 

NAME: 

"complete cone demo" 

DOCUMENTATION : 

"This is the main KA 
that will start the cone demo" 

PURPOSE : 

(ACHIEVE cone_demo) 

CONTEXT : 

(FACT vehicle_status "True") 


(FACT demo_done "False") 

BODY: 

(1 (ACHIEVE vehicle_initialized) 2) 

(2 (ACHIEVE road_scouted) 3) 

} 

// 

// KA 2 

// 

KA { 

NAME: 

"initialized vehicle" 

DOCUMENTATION : 

"initialized all the vehicle controls" 
PURPOSE : 

(ACHIEVE vehicle_initialized) 

CONTEXT : 

(FACT vehicle_status "True") 

(FACT demo_done "False") 


BODY: 

(99 

(1 

(EXECUTE init_database 
(EXECUTE home_robot $x 

2) 1) 

$y $ to ) 2) 

(2 

(ASSERT 

vehicle_ini tali zed) 

3) 

(3 

(ASSERT 

YARF 

2) 

4) 

(4 

(ASSERT 

APPROACHCONE 

4) 

5) 

(5 

(ASSERT 

OFFROAD 

8) 

6) 

(6 

(ASSERT 

CHECKVEHICLE 

16) 

7) 

(7 

(ASSERT 

STOPPED 

2) 

8) 

(8 

(ASSERT 

CONEFOUND 

4) 

9) 

(9 

(ASSERT 

MAXDIST 

8) 

10) 

(10 

(ASSERT 

READCHEDCONE 

16) 

11) 

(11 

(ASSERT 

READCHEDVEHICLE 32) 

12) 

(12 

(ASSERT 

VEHICLESTATUS 

64) 

13) 


// 

// KA 3 

// 

KA { 

NAME: 

"road scouted" 

DOCUMENTATION: 

"This KA will scout out a road, 
as per the scenario plan" 

PURPOSE : 

(ACHIEVE road_scouted) 

CONTEXT : 

(FACT vehicle_status "True") 

(FACT demo_done "False") 

BODY: 

(1 (ACHIEVE road_f ollowed_until„cone) 2) 
(OR 

((2 (FACT cone_found $value) 3) 

(3 (TEST (== $ value "True")) 5) 

(5 (ACHIEVE cone_approached) 6) 

(6 (FACT cone__reached $value) 7) 

(7 (TEST (== $ value "True")) 8) 

(8 (ACHIEVE traveled_of f_road) 9) 


847 


(9 (FACT vehicle_reached $value) 10) 
(10 (TEST (== $value "True")) 11) 

(11 (ASSERT demo_done "True") 12)) 

( (2 (FACT vehicle_maxdist $value) 20) 
(20 (TEST (== $value "True")) 21) 

(21 (ASSERT demo__done "True") 12))) 

} 

// 

// KA 4 

// 

KA { 

NAME: 

" r oad_f o 1 1 owed_un t i l_cone " 

DOCUMENTATION: 

"This KA will follow the road 
until the vehicle sees a cone 
or passes the turn off point" 

PURPOSE : 

(ACHIEVE road_f ol lowed_unti l_cone ) 
CONTEXT : 

(FACT vehicle_status "True") 

(FACT cone_found "False") 

(FACT vehicle_maxdist "False") 

(FACT YARF $YARF) 

(FACT STOPPED $ STOPPED) 

(FACT CONEFOUND $CONEFOUND) 

(FACT MAXDIST $MAXDIST) 

BODY: 

(1 (EXECUTE start_behavior $YARF ) 2) 

(2 (EXECUTE check__behavior 
$ STOPPED 

$vehicle_stopped) 3) 

(3 (FACT vehicle_stopped $value) 4) 

(OR 

((4 (TEST (== $ value "False")) LOOP 2)) 
((4 (TEST (== $ value "True")) 5) 

(5 (EXECUTE checkjoehavior 
$ C ONE F OUND 
$cone_found) 6) 

(6 (ASSERT cone_found 

$cone_found) 7) 

(7 (EXECUTE checkjoehavior 
$MAXDIST 

$vehicle_maxdist ) 8) 

(8 (ASSERT vehicle_maxdist 

$vehicle_maxdist) 9))) 

/* 

start YARF behavior 
while (not done) 
if (vehicle stopped) 
done = true 

if (vehicle max distance) 
stop all, 

we are done with demo, 
mission was not accomplished 
else if (cone found) 
assert found cone 

*/ 

} 

// 

// KA 5 


// 

KA { 

NAME: 

" cone_approached " 

DOCUMENTATION : 

"When the vehicle sees the cone, 
it approaches it" 

PURPOSE : 

(ACHIEVE cone_approached) 

CONTEXT : 

(FACT vehicle_status "True") 

(FACT cone_reached "False") 

(FACT APPROACHCONE $APPROACHCONE ) 

(FACT STOPPED $ STOPPED) 

(FACT REACHEDCONE $REACHEDCONE ) 

BODY: 

(1 (EXECUTE start_behavior 

$ APPROACHCONE) 2) 

(2 (EXECUTE check__behavior 
$ STOPPED 

$vehicle_stopped) 3) 

(3 (FACT vehicle_stopped $value) 4) 

(OR 

((4 (TEST (== $value "False")) LOOP 2)) 
((4 (TEST (== $value "True")) 5) 

(5 (EXECUTE check_behavior 
$REACHEDCONE 
$cone_reached) 6) 

(6 (ASSERT cone_reached 

$cone_reached) 7) ) ) 

/* 

start approach cone behavior 
while (not done) 

if (vehicle stopped) 
done = true 
if (reached cone) 
assert at cone 

*/ 

} 

// 

// KA 6 

// 

KA { 

NAME: 

" traveled_of f_road" 

DOCUMENTATION : 

"When the vehicle is at the cone, 
it does some off roading" 

PURPOSE : 

(ACHIEVE travel ed_of f_road) 

CONTEXT : 

(FACT vehicle_status "True") 

(FACT vehicle_reached "False") 

(FACT STOPPED $STOPPED) 

(FACT REACHEDVEHICLE $REACHEDVEHICLE) 
(FACT OFFROAD $ OFFROAD) 

BODY: 

(1 (EXECUTE start_behavior $ OFFROAD) 2) 
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(2 (EXECUTE check_behavior 

$STOPPED $vehicle_s topped) 3) 
(3 (FACT vehicles topped $value) 4) 

(OR 

((4 (TEST (== $value "False")) LOOP 2)) 
((4 (TEST (== $value "True")) 5) 

(5 (EXECUTE check_behavior 
$ REACHEDVEH ICLE 
$vehicle_reached) 6) 

(6 (ASSERT vehicle_reached 

$vehicle_reached) 7 ) ) ) 

/* 

start off road behavior 
while (not done) 
i if (vehicle stopped) 

done = true 
if (reached vehicle) 
assert at vehicle 

*/ 

} 

// 

// KA 7 

// 

KA { 

NAME: 

"vehicle_status_checked" 

DOCUMENTATION : 

"Check to make sure the vehicle is ok 
\ once in a while" 

| 

PURPOSE : 

(ACHIEVE vehicle_status_checked) 

CONTEXT : 

(FACT CHECKVEHICLE $CHECKVEHICLE ) 

(FACT VEHICLESTATUS $ VEHICLE STATUS) 

BODY: 

(1 (EXECUTE start_behavior 

$CHECKVEHICLE) 2) 

(2 (EXECUTE check_behavior 
$VEH ICLE STATUS 
$vehicle_status ) 3 ) 

(3 (ASSERT vehicle_status 

$vehicle_status) 4) 

/* 

if (vehicle status != OK) 
stop vehicle, stop prs 

*/ 

} 
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